home *** CD-ROM | disk | FTP | other *** search
- Date: Mon, 30 May 1994 15:39:21 -0400 (EDT)
- From: Timothy Miller <millert@undergrad.csee.usf.edu>
- Subject: Re: Colour.
- To: gem-list@world.std.com
- In-Reply-To: <199405301408.QAA08792@blade.stack.urc.tue.nl>
- Message-Id: <Pine.3.87.9405301521.D17681-0100000@undergrad>
- Mime-Version: 1.0
- Precedence: bulk
-
-
-
- On Mon, 30 May 1994, Erlend Nagel wrote:
-
- >
- > Simon Gornall wrote:
- >
- > > A program (GEMCMS.PRG) in the auto folder could register the cookie, and
- > > reserve mem for (say) 30 apps. Have a .cpx that llows you to configure this on
- > > the fly, and then you just need binding support (libgem.olb could incorporate
- > > it easily, lattice/pure/any other may have more difficulty - for these a
- > > separate lib may be necessary.)
- >
- > I don't like the idea of having a certain limit of applications a colour
- > manager can handle, even if it is user configurable. I'd say especially
- > if it is user-configurable. I consider myself a pretty standard user
- > (whatever that is) and I don't like it when I have to configure things.
- > It is best I think if our colour manager would allocate memory on the
- > dynamically.
- >
- > Erlend.
- >
-
- No limits, please. The manager should use the handle of each window as
- the handle the app will use when setting/resetting a palette. When a
- window is topped/untopped, the app should pass the window handle and a
- flag for whether the window was topped or untopped. This way, the system
- could manage a seperate palette for each WINDOW.
-
-
-